Jeg er ikke sikker på hvordan jeg virkelig kan sette spørsmålstegn ved ordene mine, så la meg prøve å forklare det med et eksempel: La oss si at programmet mitt får litt merkelig oppførsel ved en bestemt handling. Jeg har allerede funnet noen kode som er årsaken til denne rare oppførselen. Når jeg deaktiverer denne sekvensen, støter jeg ikke på denne oppførselen. Dessverre trenger jeg denne koden fordi noe annet ikke fungerer da. Så det jeg skal gjøre er å finne ut hvorfor noe går annerledes når kodekodet er aktivt. For å bedre forstå hva som skjer, vil jeg noen ganger kjøre hele handlingen inkludert den 'dårlige koden' og noen ganger uten. Da kan jeg sammenligne utfallet, for eksempel hva som skjer i brukergrensesnittet eller hva funksjonen min returnerer. Den første tilnærmingen som kommer opp i tankene mine er å kjøre programmet mitt med koden aktivert, gjøre hva jeg vil, så stoppe programmet, kommentere koden, kompilere og kjøre igjen. Um ... det høres dumt ut. Spesielt hvis jeg igjen trenger å slå på den koden for å se en annen gang den andre oppførselen, og deretter igjen slå av, og på, og av og så videre. Det er ikke et alternativ for meg å bruke brytepunkter og påvirke utsagnets rekkefølge eller å endre verdier slik at jeg får eller ikke får inn if-setninger, for-loops etc. To eksempler: Jeg feilsøker en kritisk atferd for timing, og når jeg stopper programmet, endres timingen betydelig. Dermed må det første brytpunktet jeg kan sette være på slutten av handlingen. 1 Jeg forventer at det vises et verktøytips eller et annet vindu som er 'undertrykt' når VS blir fokusert. Dermed kan jeg ikke bruke noen bruddpunkter i det hele tatt. Verken i begynnelsen eller på slutten av handlingen.1 Er det noen teknikk i Visual Studio 2012 som lar meg merke denne koden for å være valgfri, og jeg kan bestemme om jeg vil kjøre denne kodesekvensen før jeg utfører handlingen? Jeg tenker på noe som hvis (true | false) på et høyere nivå. Jeg leter ikke etter en løsning der jeg trenger å kjøre programmet mitt flere ganger. I så fall kunne jeg fortsatt gjøre den enkle tilnærmingen å bare kommentere koden med #if false. 1 Merk at jeg selvfølgelig kan sette et brytpunkt når jeg trenger å se på en bestemt variabel på en bestemt posisjon (hvis jeg ikke har skrevet verdien til utdata), men vil slå av brytepunkter igjen for å kjøre hele handlingen i ett gå.
2020-12-07 23:10:36
I Visual Studio-feilsøkingsprogrammet kan du angi et brytpunkt rett foran "den aktuelle koden". Når koden stopper på det punktet, kan du velge å la den fortsette, eller du kan høyreklikke på en hvilken som helst annen linje og velge Angi neste uttalelse.
Det er litt av et merkelig alternativ, men jeg har forstått det.
|
Det eneste alternativet jeg kan tenke meg er å legge til noe i brukergrensesnittet ditt som bare vises når du feilsøker, og gir deg muligheten til å inkludere / ekskludere de aktuelle operasjonene.
Mens du er i gang, vil du kanskje også aktivere tilbakestilling av applikasjonen til en "kjent tilstand" fra brukergrensesnittet.
|
Jeg tenker på noe som hvis (true | false) på et høyere nivå.
Hvorfor "på et høyere nivå"? Hvorfor ikke bruke akkurat dette?
Du vil at et stykke kode noen ganger skal utføres, noen ganger ikke, og bryteren skal endres på kjøretid, ikke på kompileringstidspunktet - dette fører selvsagt til
hvis (tilstand)
{
// kode i innsats
}
Fangsten her er hva slags tilstand du vil bruke - kanskje en variabel du setter til sann i utgivelsesversjonen av koden din, og til falsk noen ganger i feilsøkingsversjonen din. Kanskje verdien er hentet fra en konfigurasjonsfil, kanskje fra en miljøvariabel, kanskje beregnet av noen form for logikk i programmet ditt, uansett og når du vil.
EDIT: du kan også introdusere en boolsk variabel i koden din for tilstand, initialisere den til true som standard og endre verdien ved hjelp av feilsøkingsprogrammet når du vil.
|
Preprocessor Directives kan være det du er ute etter. De er kodebiter som kompilatoren kan utføre, identifiserbare ved å starte med et #-tegn (og stilistisk følger de som standard ikke innrykkmønsteret til koden din, i stedet for alltid å ligge godt til venstre i redaktøren ):
#define INCLUDE_DODGY_CODE
offentlig ugyldig MyMethodWithDodgyBits () {
# hvis INCLUDE_DODGY_CODE
myDodgyMethod ();
#slutt om
myOkMethod ();
}
I dette tilfellet, hvis #define INCLUDE_DODGY_CODE ble inkludert, blir myDodgyMethod () samtalen samlet inn i programmet ditt. Ellers blir samtalen hoppet over av kompilatoren og vil ganske enkelt ikke eksistere i din binære fil.
|
Det er et par alternativer for feilsøking som du spør.
Visual Studio har en rekke alternativer for å navigere direkte gjennom koden. Du kan bruke Set Next Statement-funksjonen til å flytte direkte til en bestemt uttalelse. Du kan også redigere verdier direkte gjennom Umiddelbart vindu QuickWatch og verktøytipsen som svever over variabler under feilsøking.
Visual Studio har også muligheten til å spille av kjøringshistorikken. Ta en titt på IntelliTrace for å komme i gang. Det kan være nyttig når du har flere bekymringsområder som samhandler og genererer feiltilstanden.
Du kan også pakke kodedelene dine inn i betingede blokker, og angi de betingede variablene etter behov. Det kan være mens du feilsøker, eller du kan sende parametere gjennom en konfigurasjonsfil. Det kan være enklere å bruke betingede kontroller enn å gå gjennom koden manuelt hvis det er flere utsagn du vil ekskludere.
|
Noen ganger avhenger det av versjonen av VS og språket, men du kan med glede redigere koden (for å kommentere den, eller pakke den inn i en stor #ifdef 0), og trykk deretter på alt + F10 og kompilatoren kompilerer på nytt, kobler på nytt og fortsetter kjøringen som om du aldri hadde fiklet med det.
Men mens det fungerer vakkert i VC ++ (siden VS v6 IIRC), kan C # ha problemer - jeg finner (med VS2010) at jeg ikke kan redigere og fortsette på denne måten med funksjoner som inneholder noen lambda-setninger (hovedsakelig linq) og 64-biters kode aldri brukt til å gjøre dette også. Likevel er det verdt å eksperimentere med det er veldig nyttig noen ganger.
|
Jeg har jobbet med applikasjoner som har valgfri kode som brukes til feilsøking alene som ikke skal vises i produksjonsmiljøet. Dette segmentet med valgfri kode var enklest for oss å kontrollere ved hjelp av en konfigurasjonsfil siden det ikke krevde en ny kompilering for å endre.
En slik løsning er kanskje ikke slutten på alt for sluttresultatet ditt, men det kan hjelpe å komme gjennom den til en løsning er funnet. Hvis du har flere valgfrie seksjoner som må testes i kombinasjon, kan denne løsningen kreve flere nøkler i konfigurasjonsfilen, noe som kan være en ulempe og en smerte å holde styr på.
|
Spørsmålet ditt er ikke helt klart, og det er muligens grunnen til at det er så mange svar som du mener er ugyldige. Det kan være lurt å vurdere å omformulere det hvis ingen ser ut til å kunne svare på spørsmålet.
Med risiko for å gi et annet ugyldig svar, vil jeg legge til noen innspill om hvordan jeg har håndtert problemet tidligere.
Den enkleste måten er å plassere valgfri kode i
# hvis DEBUG
// Valgfri kode her
#slutt om
På den måten, når du kjører i feilsøkingsmodus, implementeres koden, og når du kjører i frigjøringsmodus er den ikke. Bytte mellom de to krever å klikke på en knapp.
Jeg har også løst det samme problemet på en lignende måte med et enkelt flagg:
bool runOptionalCode = false;
deretter
hvis (runOptionalCode)
{
// Plasser valgfri kode her
}
En gang til,å bytte mellom modusene krever å endre ett ord, så det er en enkel oppgave. Du nevner dette i spørsmålet ditt, men diskonterer det av grunner som er uklare. Som sagt krever det veldig lite arbeid å bytte mellom de to.
Hvis du trenger å gjøre endringer mellom koden mens den kjører, er den beste måten å bruke et UI-element eller et tastetrykk som endrer flagget nevnt i eksemplet ovenfor. Avhengig av søknaden din, kan dette være mer innsats enn det er verdt. Tidligere har jeg funnet ut at når jeg har en nøkkellytter som allerede er implementert som en del av prosjektet, å ha et par tastetrykk bestemme om jeg skal kjøre feilsøkingskoden (valgfri) fungerer best. I et program uten nøkkellyttere vil jeg helst holde meg til en av de forrige metodene.
|
Ditt svar
StackExchange.ifUsing ("editor", function () {
StackExchange.using ("externalEditor", funksjon () {
StackExchange.using ("snippets", function () {
StackExchange.snippets.init ();
});
});
}, "kodebiter");
StackExchange.ready (funksjon () {
var channelOptions = {
tagger: "" .split (""),
id: "1"
};
initTagRenderer ("". split (""), "" .split (""), channelOptions);
StackExchange.using ("externalEditor", funksjon () {
// Må utløse redaktøren etter utdrag, hvis utdrag er aktivert
hvis (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using ("snippets", function () {
createEditor ();
});
}
annet {
createEditor ();
}
});
funksjon createEditor () {
StackExchange.prepareEditor ({
useStacksEditor: false,
hjerteslagType: 'svar',
autoActivateHeartbeat: false,
convertImagesToLinks: sant,
noModals: sant,
showLowRepImageUploadWarning: true,
reputToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Drevet av \ u003ca href = \" https: //imgur.com/ \ "\ u003e \ u003csvg class = \" svg-icon \ "width = \" 50 \ "height = \" 18 \ "viewBox = \ "0 0 50 18 \" fill = \ "none \" xmlns = \ "http: //www.w3.org/2000/svg \" \ u003e \ u003cpath d = \ "M46.1709 9.17788C46.1709 8.26454 46.2665 7.94324 47.1084 7.58816C47.4091 7.46349 47.7169 7.36433 48.0099 7.26993C48.9099 6.97997 49.672 6.73443 49.672 5.93063C49.672 5.22043 48.9832 4.61182 48.1414 4.61182C47.4335 4.61182 46.7256 4.916 43.1481 6.59048V11.9512C43.1481 13.2535 43.6264 13.8962 44.6595 13.8962C45.6924 13.8962 46.1709 13.2535 46.1709 11.9512V9.17788Z \ "/ \ u003e \ u003cpath d = \" M32.492 10.1419C4.4.014.42 12.6 12.4 41.5985 12.6954 41.5985 10.1419V6.59049C41.5985 5.28821 41.1394 4.66232 40.1061 4.66232C39.0732 4.66232 38.5948 5.28821 38.5948 6.59049V9.60062C38.5948 10.8521 38.2696 11.5455 37.0451 11.545.5 521 35.4954 9.60062V6.59049C35.4954 5.28821 35.0173 4.66232 34.0034 4.66232C32.9703 4.66232 32.492 5.28821 32.492 6.59049V10.1419Z \ "/ \ u003e \ u003cpath fill-rule = \" evenodd \ "clip-rule = \" evend = \ "M25.6622 17.6335C27.8049 17.6335 29.3739 16.9402 30.2537 15.6379C30.8468 14.7755 30.9615 13.5579 30.9615 11.9512V6.59049C30.9615 5.28821 30.4833 4.66231 29.4502 4.66231C28.9913.566.461.56 .1369 4.56087 21.0134 6.57349 21.0134 9.27932C21.0134 11.9852 23.003 13.913 25.3754 13.913C26.5612 13.913 27.4607 13.4902 28.1109 12.6616C28.1109 12.7229 28.1161 12.7799 28.121 12.8346C28.125.226 15.2321 24.1352 14.9821 23.5661 14.7787C23.176 14.6393 22.8472 14.5218 22.5437 14.5218C21.7977 14.5218 21.2429 15.0123 21.2429 15.6887C21.2429 16.7375 22.9072 17.6335 25.6622 17.63351724.224.17 27.2119 7.09766 28.0918 7.94324 28.0918 9.27932C28.0918 10.6321 27.2311 11.5116 26.1024 11.5116C24.9737 11.5116 24.1317 10.6491 24.1317 9.27932Z \ "/ \ u003e \ u003cpath d = \" M16.8045 11.95129.66.280.26 19.8079 13.2535 19.8079 11.9512V8.12928C19.8079 5.82936 18.4879 4.62866 16.4027 4.62866C15.1594 4.62866 14.279 4.98375 13.3609 5.88013C12.653 5.05154 11.6581 4.62866 10.3573 4.62866C9.34336 4.62866 8.57806 4.89966 5.00066 5.28821 5.00066 6.59049V11.9512C5.00066 13.2535 5.47873 13.8962 6.51203 13.8962C7.54479 13.8962 8.0232 13.2535 8.0232 11.9512V8.90741C8.0232 7.58817 8.44431 6.91179 9.53458 6.91179C11.510.610.810 C13.4375 13.8962 13.9157 13.2535 13.9157 11.9512V8.90741C13.9157 7.58817 14.3365 6.91179 15.4269 6.91179C16.4027 6.91179 16.8045 7.58817 16.8045 8.94108V11.9512Z \ "/ \ u003e \ u003cpath d = \ "M3.31675 6.59049C3.31675 5.28821 2.83866 4.66232 1.82471 4.66232C0.791758 4.66232 0.313354 5.28821 0.313354 6.59049V11.9512C0.313354 13.2535 0.791758 13.8962 1.82471 13.89622.813.2535 3.31675 11.9512V6.59049Z \ "/ \ u003e \ u003cpath d = \" M1.87209 0.400291C0.843612 0.400291 0 1.1159 0 1.98861C0 2.87869 0.822846 3.57676 1.87209 3.57676C2.90056 3.57676 3.7234 2.97869 0.400291Z \ "fill = \" # 1BB76E \ "/ \ u003e \ u003c / svg \ u003e \ u003c / a \ u003e",
contentPolicyHtml: "Brukerbidrag lisensiert under \ u003ca href = \" https: //stackoverflow.com/help/licensing \ "\ u003ecc by-sa \ u003c / a \ u003e \ u003ca href = \" https://stackoverflow.com / legal / content-policy \ "\ u003e (policy for innhold) \ u003c / a \ u003e",
allowUrls: sant
},
onDemand: sant,
discardSelector: ".discard-answer"
, straksShowMarkdownHelp: true, enableSnippets: true
});
}
});
Takk for at du bidro med svaret på Stack Overflow!
Sørg for å svare på spørsmålet. Gi detaljer og del din forskning!
Men unngå ...
Be om hjelp, avklaring eller svare på andre svar.
Å komme med uttalelser basert på mening; sikkerhetskopier dem med referanser eller personlig erfaring.
For å lære mer, se tipsene våre for å skrive gode svar.
Utkast lagret
Utkast kastet
Registrer deg eller logg inn
StackExchange.ready (funksjon () {
StackExchange.helpers.onClickDraftSave ('# login-link');
});
Registrer deg ved hjelp av Google
Registrer deg ved hjelp av Facebook
Registrer deg ved hjelp av e-post og passord
Sende inn
Legg ut som gjest
Navn
E-post
Påkrevd, men aldri vist
StackExchange.ready (
funksjon () {
StackExchange.openid.initPostLogin ('. New-post-login', 'https% 3a% 2f% 2fstackoverflow.com% 2fquestions% 2f19425104% 2fcan-i-mark-some-code-as-optional-while-debugging-in- visual-studio-2012% 23new-answer ',' question_page ');
}
);
Legg ut som gjest
Navn
E-post
Påkrevd, men aldri vist
Legg ut svaret ditt
Kast
Ved å klikke på “Legg ut svaret ditt” godtar du vilkårene for bruk, personvern og policy for informasjonskapsler
Er ikke svaret du leter etter? Bla gjennom andre spørsmål merket feilsøkingsstudio eller still ditt eget spørsmål.